1. Field of the Invention
The present invention relates to increased Internet Protocol Headers compression performance by reporting cause of missing packets.
2. Description of the Related Art
Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocols (IP) over all kinds of network links. IP usually refer to numerous packet switching protocols such as IPv4 (Internet protocol version 4), IPv6 (Internet protocol version 6), UDP (User Datagram Protocol), UDP-Lite, TCP (Transport Control Protocol), RTP (Real-time Protocol), etc. An IP packet is usually composed of a payload of information sequentially encapsulated in one or more IP protocols. Reference is now made to the Drawings wherein FIG. 1 shows an exemplary IP packet 100 formed by a payload 110, a RTP header 140, a UDP header 130 and an IPv4 header 120. The IP packet 100 is referred to as an IPv4/UDP/RTP packet. For simplicity purposes, the headers 120, 130 and 140 are usually jointly referred to as IP headers 150. It should be understood that other sets and subsets of IP protocols each having different header configurations can be used to form the IP packet 100 and the IP headers 150. Each header 120, 130 and 140 of the IP headers 150 carries specific information about the IP packet 100, which information is used by the destination of the packet 100 to interpret the payload 110. The carried information in the IP headers may include origination and destination of the IP packet 100, associated quality of service information, a sequence number, checksum information for integrity of the payload, etc. One drawback of IP is the large size of the IP headers. It is not a simple task to make use of IP over narrow band network links as, for example, cellular links. As an example, using the IP protocols for ordinary speech data (e.g. Voice-over-IP or VoIP using IPv4/UPD/RTP or IPv6/UPD/RTP) may represent a loss of as much as 70% of the bandwidth capacity of a given network link.
The term header compression (HC) comprises the art of minimizing the necessary bandwidth used by the IP headers. It is usually performed on a per-hop basis over point-to-point network links. Header compression techniques, in general, have a more than ten-year-old history within the Internet community. Several techniques commonly used are described in the following documents: RFC 1144 [VJ], RFC 2507 [IPHC] and RFC 2508 [CRTP], all herein included by reference. Header compression takes advantage of the fact that some fields in the IP headers are not changing (static) within a stream of packet pertaining to a given packet flow, or change with small or predictable values. Header compression techniques make use of these characteristics and send static information only initially, while changing fields are sent with their absolute values or as differences from packet to packet. Completely random information has to be sent without any compression at all. The challenging task of any header compression technique is to keep both ends of the network link consistent with each other. For that purpose, a compressor at one end and a decompressor at the other end each make use of a compression context. The use of the compression contexts aims at keeping the IP headers size as low as possible. To do so, each end manages all necessary information to eliminate some fields (totally or partially) from the IP headers at the compressor end and to rebuild the IP headers at the decompressor end.
Header compression techniques are thus an important component to make VoIP over Wireless (VoIPoW) an economically feasible alternative to circuit switched voice. For this purpose, some header compression techniques have been developed by the Robust Header Compression (ROHC) Working Group of the Internet Engineering Task Force (IETF). RFC 3095 [ROHC] and RFC 3242 [LLA] herein included by reference, describes an extensible framework for which profiles for compression of various networking protocols may be defined. The following example takes the header compression technique defined in ROHC as an example. In such a case, the compression contexts of both the compressor and the decompressor contain and maintain relevant information about past packets, which information is used to compress and decompress subsequent packets. More precisely, ROHC says the following: “The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as “context”, when it is clear which is intended. The context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet stream [or flow] is also part of the context, for example information about how the IP Identifier field changes and the typical inter-packet increase in sequence numbers or timestamps.”
In order to work properly, each header compression technique requires an initialization phase during which the compressor and the decompressor build their respective compression context. This phase is usually referred to as the context initialization phase. It usually requires the compressor to start using a low compression state. Initially, the transmitted packets contain the information necessary to initialize at least the static and maybe the dynamic part of the decompressor context. The compressor must then have enough confidence that the decompressor has the proper context before a transition to a higher compression ratio takes place. This confidence may be achieved using explicit feedback from the decompressor to the compressor, or by sending a number of context initialization packets repeatedly for a large enough interval. The use of explicit feedback requires at least one Round-Trip Time (RTT) period before confidence may be achieved. The use of a predetermined number of packets may achieve confidence in less than one RTT period but cannot absolutely guarantee that the decompressor does have the proper context other than optimistically expect to be successful with a high percentage rate. The maximum compression ratio achievable on a given link largely depends on the header compression technique used thereon. However, it takes several phases of confidence/transition before reaching the maximum compression ratio of a given compression technique.
The described problem also causes other problems when the compression context must be reinitialized during a session. It mainly happens when too many packets or frame are lost during a transmission. The compression context must be reinitialized completely (e.g. both static and dynamic portions), in parts (e.g. static portion only) or updated (e.g. selected fields modified) after it has been invalidated. The invalidation criteria are usually specified by an Optimistic Approach Agreement (OAA) between the compressor and decompressor, as defined in [LLA] (Link-Layered assisted). The OAA specifies the maximum number of dropped or missing packets acceptable before deciding that a compression context should be invalidated or that a lower compression ratio should be applied. After invalidation, the compression context should be reinitialized. In some occasions, the dropped packets are due to the use of the link for more prioritized packets such as signaling packets. However, the information about the dropped packets is not available to the compressor and decompressor when they take their decision to invalidate and later on reinitialize the compression context. This situation causes a certain delay for which the compression efficiency is far from optimal or totally null. It further causes packets to be lost between the invalidation decision and completion of the re-initialization. In the example of VoIP flows over very narrow bandwidth wireless links, such delay and losses impact the perceived quality of speech until optimal compression efficiency is reached again.
As it can be appreciated, there is a need for an increased Internet Protocol (IP) Headers compression performance by reporting cause of missing packets.